feat: sms: scheme - #454

The previous sanitizeBody approach (strip <>"' then strip script/alert/javascript)
left residual content after multi-pass stripping. For example:
  <script>alert("xss")</script>
  → after step 1: scriptalert(xss)/script
  → after step 2: (xss)/            ← fails test expectation of empty string

Decode URL encoding first to catch encoded payloads, then reject the entire
body value if angle brackets are present (the primary HTML injection vector),
rather than attempting partial character stripping that can be bypassed.

Also re-encode the output so decoded bodies (e.g. Hello%20World) round-trip
correctly through the URL attribute context.

Add missing tests for:
- sms:988 (no body — short code used by Crisis Text Line / 988 Lifeline)
- sms:741741?body=SEIZE (RFC 5724 ?body= input normalised to &body= output)
- sms:741741&body=SEIZE (short code with body round-trip)

Two ways a message was silently dropped. The field name was matched case-sensitively, so sms:5555?BODY=HOME lost the body even though RFC 5234 makes the RFC 5724 literal case-insensitive; match it in any case and always emit it lower-case. sanitizeBody() then rejected the whole body when it decoded to contain "<" or ">" and deleted any quote, so sms:911?body=I%20%3C3%20you lost the message and He said "hi" became He said hi.

Neither control was load-bearing. rawurlencode() already percent-encodes <>'" so the value cannot terminate the attribute or open a tag, and HTMLPurifier_Generator::escape() escapes the attribute on top of that; mailto, which also takes ?body=, does no body sanitization at all. Reduce the method to rawurlencode(rawurldecode($body)).

The existing literal-<script> tests never reached sanitizeBody, since HTMLPurifier_URIParser excludes ["<>] from the path and query and had already emptied the body; add cases that use percent-encoded markup so the code actually runs, and pin the round trip at the AttrDef level where the generic encoder runs first.

sms://5551234?body=Send%20money parsed the recipient into the authority, which doValidate discarded, leaving sms:?body=Send%20money — the attacker-supplied message survived while the number it was addressed to did not.

Keep the authority as a fallback recipient candidate so the number is recovered, and drop the body whenever the cleaned phone number is empty, so a bodied recipient-less link is never produced. A non-numeric authority such as sms://example.com?body=hi now reduces to sms: rather than keeping the message. Recipients written with a leading plus are still lost to HTMLPurifier_URI::validate(), which rejects them as hostnames before the scheme runs; the body is dropped in that case too.

Extract the digits-and-leading-plus reduction into cleanPhoneNumber() now that it runs against two candidates.

The class docblock claimed each body form is "re-emitted the way it came in", which only holds when one form is present; a query body overrides a path body, including when that value is empty. Say so, note that reading the body depends on %URI.AllowedSymbols keeping "&" and "=", and match the comment register the sibling schemes use rather than explaining at length.

Assign path and query once as defaults and override only when a body exists, instead of repeating both across three branches.